t3code: add server service - #9695
Conversation
|
Pushed an empty commit to re-trigger CI. The only failing check was on the The t3code service derivations themselves build fine on that same builder — including the Darwin launchd test ( @iamanaws — do you know if t3code currently builds on the Darwin builder on master? If this |
Add a `programs.t3code.server` sub-module that runs the t3code headless server as a user service — systemd on Linux, launchd on Darwin — mirroring programs.opencode.web. It exposes `enable`, `extraPackages`, `extraArgs`, and `environmentFile`.
8a17782 to
310ddb1
Compare
|
Update: the empty commit was a no-op — nixbot is content-addressed, so an identical tree just replayed build #258's cached result. Rebased onto current master ( |
|
Conclusive on the darwin failure: the rebase forced a fresh build (#264, 26 derivations rebuilt), and it fails on the exact same Two independent from-scratch builds (#258 and #264) crash byte-for-byte the same way, so this is deterministic, not a flake. It's the Darwin So no author-side retrigger or change will clear this — the fix has to come from nixpkgs (a |
Description
Adds a
programs.t3code.serversub-module that runs the t3code headless serveras a user service.
programs.t3codealready manages this tool's configuration(
userSettings,keybindings,clientSettings); this lets you also run it.The service is defined for both platforms —
systemd.user.serviceson Linux andlaunchd.agentson Darwin — mirroringprograms.opencode.web.New options under
programs.t3code.server:enableextraPackages— placed on the server's PATH so t3code can shell out to thecoding-agent / VCS CLIs it drives (git, gh, claude-code, opencode, …)
extraArgs— passed tot3 serve(e.g.--host,--port)environmentFile— for secrets, without exposing them in the Nix storehost/portare intentionally not modelled as explicit options:t3 servehas sensible defaults and accepts them as flags, so they go through
extraArgs(matching
programs.opencode.web).Why
programs.t3code.serverand notservices.t3codeI extended the existing
programs.t3codemodule rather than adding a standaloneservices.t3code, for two reasons: (1)programs.t3codealready owns thistool's configuration, so keeping the service in the same module keeps the whole
tool under one namespace; and (2) it mirrors
programs.opencode.web, the closestexisting module (a coding-agent tool with config plus an optional web server).
That said, I have no strong opinion here — if you'd prefer this as a
services.t3codemodule, I'm happy to move it.Checklist
tests/modules/programs/t3code/server.nix) asserting thegenerated unit on both Linux (systemd) and Darwin (launchd).
nix build .#test-allpasses;nixfmt/treefmtclean.jonocodeshandle.server.enable = false).